Chip 1996 April

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 9301 / STCKR300.CD < prev next >

Wrap

Text File | 1995-04-18 | 33KB | 532 lines

@VSzebb és sokoldalúbb@N @VStacker 3.00 for Windows and DOS@N Egyre népszerûbbek a röptömörítôk. Gyermekbetegségeikbôl rég kigyógyultak, s legelterjedtebb képviselôjük, a Stacker a DOS után a Windowst is célba vette. Nemrég jutott el hozzánk a Stacker harmadik verziója. Most már @KStacker for Windows and DOS@N a neve a kaliforniai Carlsbadban székelô Stac Electronics cég szoftvertermékének. Telepítéskor személyre szólóvá teszi (perszonalizálja) a telepítô lemezeken lévô file-okat. Ez segíti a kalózmásolatok eredetének kiderítését. A Stacker 3.00 legfontosabb újdonságai: @V*@N Az eddigi, DOS alatti segédprogramjait továbbfejlesztették, s megjelent ezek Windows-változata is. @V*@N A Stacker által kezelt ""virtuális" lemezmeghajtók (ahol tömörítve tárolja a file-okat) jelszavas védelemmel láthatók el. Ráadásul kétféle jelszó is megadható: az egyik ismeretében ugyan olvashatók a file-ok, de nem írhatók felül és nem törölhetôk (""read-only password"), a másik ismeretében pedig szabadon dolgozhatunk a virtuális lemezeken. @V*@N Az eddigi 4 és 8 Kbyte-os clusterméret mellett megjelent a 16 és 32 Kbyte-os is. Utóbbiak a nagy méretû -- például grafikus file-okat, képeket és hangfile-okat tartalmazó -- lemezeken a Stacker mûködését gyorsítják, és némileg tovább javítják a tömörítési arányát. @V*@N Kilenc fokozatból (/P=1, ..., /P=9) választhatjuk ki, hogy mennyire fontosnak ítéljük a tömörítés--kibontás (tehát általában a lemezkezelés) sebességét és a tömörítési arányt: a 9-es fokozatban tömörít a legjobban, de egyben itt a leglassabb is, s értelemszerûen: az 1-es fokozatban a legfürgébb, viszont nem a legtökéletesebb a tömörítés. A kezdeti beállítás bármikor módosítható (de csak a DOS újraindítása után lép életbe). @V*@N A Norton SpeedDiskhez hasonló töredékmentesítô (defragmentáló) programja, a SDEFRAG.EXE is többféleképp mûködhet: például kérhetjük tôle az 1-es fokozatban használt, ezért kissé ""laza" lemeztartalom 9-es fokozatú, maximális újratömörítését is a lemez rendezése mellett. Kijavították a korábbi SDEFRAG hibáját, tudniillik rendezés és maximális újratömörítés esetén eddig csökkent (!) a virtuális meghajtón szabadon maradt hely, ami elég kellemetlen mellékhatás volt... @V*@N A PREVIEW.EXE nevû segédprogrammal tömörítetlen meghajtókat vizsgálhatunk. Megadja, hogy milyen tömörítési arányt lesz képes elérni a Stacker, ha ""ráeresztjük" a meghajtóra. @V*@N A virtuális Stacker meghajtókat hordozó DOS meghajtók méretén belül szabadon növelhetô--csökkenthetô a virtuális meghajtók mérete. Teljes eltávolítás (uninstall) is kérhetô, s ezt intelligensen hajtja végre az UNSCREAT.EXE: ha nincs elég hely a tömörített file-ok számára a hordozó meghajtón, akkor ezt jelzi, s el sem indul. Ha megszakad a futása (például hálózatkimaradás miatt), akkor újraindítható; s ha sikeresen lefutott, akkor visszakapjuk a virtuális lemez tartalmát, de immár a virtuális lemezt hordozó DOS meghajtón. @V*@N Mejelent a @KStacker Toolbox@N-nak elkeresztelt STAC.COM nevû program. Ez menüs-helpes keretrendszer a Stacker segédprogramjaihoz, így könnyebb azokat használni. @V*@N Tovább javították a programok hibatûrését és alkalmazkodó képességét a különféle helyzetekhez -- a Stacker ""intelligensebbé" vált. @VTapasztalatok@N Két gépen próbáltuk ki a Stacker legfrissebb verzióját. Az egyik a legutóbbi 386SX tesztünkben részt vett Albacomp tendergép volt. Mivel a merevlemezén alig volt valami (MS DOS 5.0, Windows), ezért a Stacker gyorsan felköltözött rá. Feltûnt, hogy a telepítô program és a Stacker Toolbox egyes képernyôi csak felvillannak, majd eltûnnek. Ezek közbülsô, információs jellegû ablakok voltak, nem vártak választ, s az elôzô, gombnyomást váró ablaknál megnyomott billentyû ezeken is áthajtotta a programot. Kipróbáltuk a @KP=1@N és a @KP=9@N beállítást. A P=1 érezhetôen gyorsabb mûködést eredményezett, de csak leheletnyit. Egy gyors összehasonlítás viszont azt mutatta, hogy mintegy 5 Mbyte-nyi file-on a lazább, P=1 beállítás 1,8:1 arányú, míg a P=9 csak 1,9:1 arányú tömörítést eredményezett. (Az arányok a Stacker által mutatott, egy tizedesjegynyi pontosságú értékek.) A P=2..8 beállításokkal ezek után már nem is kísérleteztünk. Látszik, hogy itt a Stacker fô tömörítô algoritmusának árnyalatnyi módosításairól lehet csak szó. Hogy kinek-kinek melyik beállítás rokonszenves, döntse el maga. A legjobbnak talán a P=1 tûnik, az ezzel járó idônkénti lemez-újratömörítéssel és lemezrendezéssel (SDEFRAG). Második alkalommal egy szerkesztôségi, 33 MHz-es 386-os gépen telepítettük a Stacker 3.00-t (azóta is fent van rajta, további tapasztalatok szerzése céljából). A 300 Mbyte-os, 90%-ig telített merevlemezre több óra alatt ""mászott fel". Apró bibi: az egyik telepítési mûvelet közben közölte, hogy törli az üres könyvtárakat (""kioptimálta" ôket, noha az ilyen könyvtárak többnyire csak látszólag feleslegesek...). Egy 40 Mbyte-os, már tömörített (ARJ) file-t nem tudott átrakni az általa tömörített részbe, mert nem fért el ott. A telepítés végén hiba nélküli lefutást jelzett (""no errors"), az elsô DOS-beli @KCHKDSK /F@N parancs viszont rátalált az át nem vitt, 40 Mbyte-os file könyvtári bejegyzésére, s 0 byte-osra javította azt. A file persze megvolt eredeti helyén, a Stacker virtuális meghajtóját hordozó meghajtón, így kisebb ijedtség után kijelenthettük: minden rendben -- s ez az azóta eltelt idôszakra is igaz maradt. A Stacker 3.00 részletes, jól áttekinthetô jelentést tud adni az általa tömörített virtuális lemezekrôl, megadva a tömörítési arányt a lemez egészére, a file-okra kiterjesztés (.EXE, .COM stb.) szerint csoportosítva, illetve az egyes file-okra külön-külön is -- a felsorolásokat tömörítési arány, kiterjesztés stb. szerint rendezve kérhetjük egy (elôre-hátra lapozható tartalmú) ablakba. Látványos és kényelmesen használható újdonság. Nos, ez a program a nagy merevlemezen (nyilván a sok file miatt) meghívva osztási hibával elszáll, s ilyenkor újra kell indítani a gépet. Már a Stacker 2.00 verziójával is lehetett röptömöríteni floppykat. Az eredmény csigalassú floppymûködés volt, minimális tömörítés mellett (2,0:1 arányban röptömöríthetô file-oknál 1,1..1,2:1 arány). A 3.00 verziónál a floppysebesség valamelyest javult, a tömörítési arány változatlan, újdonság viszont a @KStacker Anywhere@N elnevezésû kiegészítés. Ezt egy STACKER.EXE file testesíti meg, amit a röptömörített floppy gyökérkönyvtárába rak a Stacker, negyvenegynéhány Kbyte-os, s bármely más gépen elindítható. îgy a röptömörített floppyk átvihetôk a gépek közt, tekintet nélkül arra, hogy fut-e rajtuk a Stacker. (Mellesleg: ezt a megoldást is a SuperStortól lesték el, mint oly sok másikat -- persze ez lényegtelen). Lassúsága és a minimális tömörítés miatt továbbra sem ajánljuk a floppyk tömörítését. Eddig ennyi derült ki a legújabb Stackerrôl. Komolyabb fejlesztésnek csak a jelszavas védelem és a virtuális meghajtók szabadon változtatható mérete illetve tartalmuk megôrzése melletti megszüntethetôségük nevezhetô. A Stacker 3.00 nevében a @Kfor Windows@N kitétel enyhe túlzás: a karbantartási mûveletek sem Windows, sem Desqview alatt nem indíthatók el -- ami helyes, mert multitaszkos környezetben meglehetôsen kockázatos minden ilyesmi... Bosszantó viszont, hogy mindeközben a szabad lemezterület növelésére hivatott programcsomag mérete több mint háromszorosára, jó másfél Mbyte-ra hízott. A szépség (ablakozás, Windows alatti csicsák) ennyit nem ér meg, fôleg egy rendszerprogramnál... A röptömörítô technológia tehát egy helyben topog. Tudjuk, hogy rettentôen nehéz volt kifejleszteni magát a röptömörítést (ráadásul úgy, hogy a háttérben, abszolút biztonságosan, és lehetôleg gyorsan fusson a tömörítés--kibontás) -- nem véletlenül váratott magára sokáig. S érezhetô, hogy mindaz, amit itt felsorolunk, közel ugyanilyen nehézségeket okozhat esetleg, ám sokkal több értelmük lenne, mint az -- angolból vett kifejezéssel -- csingi-lingiknek. Tehát, a vágyaink: @V*@N Ki-be kapcsolható tömörítés -- ha úgy tetszik, a P=0 lehetôsége. îgy (sebességmérési táblázatunkból látszik) a röptömörítés fô hátránya, a nyers adatátvitel lassúsága eltûnhetne, vagy legalább enyhülne. @V*@N Töredékmentesítés a háttérben (röp-töredékmentesítés). Nem valamiféle erôszakos, ""túl okos" megoldás hiányzik, hanem az, hogy a nyilvánvaló üresjáratokat -- amikor például a DOS promptnál villog a kurzor a magárahagyott gép képernyôjén -- valami hasznos célra kihasználja az operációs rendszer vagy más program. Ha ez a ""más program" a Stacker, akkor a legkézenfekvôbb, leghasznosabb tevékenység ez a ""láthatatlan SDEFRAG" lehetne. @V*@N A tömörítési arány további fokozása. Jelenleg a röptömörítôk a Liv-Zempel féle tömörítés LZS-féle módosítását használják ilyen-olyan formában. Ez tûrhetô hatásfokú, ugyanakkor rettentô gyors -- ami nagyon fontos! -- a jobban tömörítô módszerekhez képest. Az off-line (tehát kizárólagos mûködésû) újratömörítés alatt (Stackerbeli példa: @KSDEFRAG /P=9@N) viszont kevésbé fontos a gyorsaság. Ráadásul (mint a hagyományos tömörítôknél, a PKZIP-nél és az ARJ-nél jól látszik) a kibontás (""visszatömörítés") ideje a file-ok tömörített méretével arányos, így a késôbbi, on-line röpmûködés során a kibontás még gyorsulna is... @V*@N A file-használat folyamatos figyelése. A soha nem használt (soha meg nem nyitott) file-ok (ilyen a file-ok túlnyomó többsége!) lementésére, törlésére stb. ez alapján javaslatot tehetne a röptömörítô, s ugyanígy javasolhatná a néhány leggyakrabban használt file memórialemezre (RAM-diszk, RAM-drive, lásd méréseinket) rakását. Talán majd a Stacker 4.00-ban találkozunk ezek valamelyikével... Sebességmérési eredményeink és elemzésük keretes cikkeinkben olvashatók. Lapzártakor a vezetô röptömörítôk (SuperStor, Stacker) 286-os és 386SX gépeken való sebességét, illetve tömörítési arányukat vizsgáljuk. Meglepetés nem várható. Eddigi, több mint egy évig tartó használatuk során már kiderült, hogy a SuperStor sokkal gyorsabb (minden géptípuson), és nagyjából ugyanannyira tömörít. A tömörítésük közti eltérés kisebb mint 5%, s általában is elmondható, hogy bármely röptömörítô használatakor mintegy kétszer annyi (tömörítetlen) file fér a merevlemezekre, mint csupasz DOS alatt. @KBérces László@N @VMS DOS 6.0 -- DoubleDisk@N Nemrég bemutattuk az MS DOS 6.0 béta változatát, amelybe már beépítették a DoubleDisk röptömörítô program 3.00 verzióját. Októberi számunk DR DOS cikkében (54. oldal) közöltünk egy mérési táblázatot, amelyben többek között megmértük néhány röptömörítô sebességét is (MS DOS 5.0 alatt). E táblázatot most kiegészítjük a DoubleDisk 3.00 adataival. A mérések körülményeirôl októberi cikkünkben olvashatnak részletesen, most csak a legfontosabbakat foglaljuk össze. A teszteknél egy Giga-Byte típusú, 33 MHz-es 486-os gépet használtunk, 120 Mbyte-os merevlemezzel, 4 Mbyte memóriával. Az Eurotesztben használt CONFIG.SYS-ben BUFFERS=48, DOS=HIGH módosításokat tettük. A táblázatban most csak a DOS, a (leggyorsabbnak bizonyult) SuperStor 1.07 és a DoubleDisk 3.00 alatti mérési eredményeket adjuk meg. A Stacker 2.00 és az XtraDrive 1.0 eredményeit októberi számunkban találhatják meg az érdeklôdôk. A mérési adatokból csak a legfontosabbakat, az alkalmazási tesztek futási idôit hagytuk meg. DOS SuperStor 1.07 DoubleDisk 3.00 Szabad DOS memória (byte) @V*1@N: 634000 589440 590224 @VProgramok futási ideje (s)@N Turbo Pascal 5.5-teszt 54,43 49,70 64,81 dBase III Plus-teszt 146,98 178,72 259,90 DOS-teszt 64,64 57,56 77,88 Lotus 1--2--3-teszt 98,81 99,96 100,12 Windows 3.0-teszt 34,54 33,83 33,89 Word 5.5-teszt 61,02 62,94 65,85 A számokból jól látszik a DoubleDisk lassúsága (pedig a mellékelt szöveges file-ban azt írták, hogy sokat javítottak a sebességén -- hmmm...). Megkönnyíti az áttekintést, ha megnézzük az összesített futásidôket (más mérésekkel persze más arányok jönnének ki -- a lemezigényes alkalmazásokra például az elsô három sor adatai jellemzôk): DOS 460,42 másodperc (100%), SuperStor 482,71 s (104,8%), DoubleDisk 602,45 s (130,8%). Memóriaigénye a szokásos 42--44 ezer byte körüli, egyetlen szembetûnô képessége a virtuális meghajtók szabad átméretezése. Erre azonban konkurensei is képesek már (igaz, nem régóta), így kíváncsiak vagyunk, mivel próbálják lefôzni versenytársaikat?! Csak reméljük, hogy nem fogják a Microsoft új, aggresszív stílusát követve a MS DOS 6.0-val inkompatiblissé ""varázsolni" a többi röptömörítôt... @VSebesség@N Nagyon kíváncsiak voltunk az új Stacker sebességére. Kezelési kényelmével, szolgáltatásaival eddig sem volt ellenszenves, de a korábbi verziók, az 1.00, 1.10 és a 2.00 érezhetôen visszafogták a lemezmûveletek sebességét, különösen az írási mûveletekét. Kézikönyve (mint minden röptömörítôé) ezért is javasolja, hogy a Windows ""átmeneti cserefile"-ját (temporary swapfile) tömörítetlen (DOS) meghajtóra rakjuk. Októberi táblázatunkból azonban kiderül, hogy (az 1.10 verzióhoz képest sokkal fürgébb) 2.00 verzió más programokat is fékez. A méréseket 50 MHz-es Kventa 486SX gépen végeztük (81 Mbyte-os merevlemez, 4 Mbyte memória). Az eredmények mindenütt másodpercben értendôk, tehát a kisebb számok jelzik a jobb eredményeket. RAMDRIVE DOS DOS SuperStor 1.07 SuperStor 1.07 Stacker 2.00 Stacker 2.00 Stacker 3.00 Stacker 3.00 Stacker 3.00 Stacker 3.00 (cache) (cache) (cache) (P=1) (P=1, cache) (P=9) (P=9, cache) Compiler 15,16 56,80 24,83 64,42 23,29 61,57 25,32 57,23 25,43 62,67 31,26 dBase 19,60 131,60 17,63 171,80 38,99 -- -- -- -- -- -- DOS 12,02 63,16 30,97 82,00 31,36 86,83 34,71 79,20 33,72 76,62 38,72 ARJ 32,24 64,16 55,14 75,69 51,14 85,96 55,42 82,67 63,38 86,13 59,15 30 Mbyte írása 3,45 52,62 100,78 171,75 151,70 211,91 176,58 210,53 208,49 228,21 216,41 30 Mbyte olvasása 3,11 46,31 91,62 93,65 94,14 89,74 96,01 90,35 117,38 90,57 119,24 @VÖsszesen:@N dBase nélkül (%, DOS=100%) 23 100 107 172 124 189 137 184 158 192 164 dBase-zel (%, DOS=100%) 21 100 77 159 94 -- -- -- -- -- -- Méréseinkrôl néhány szót. A ""compiler" tesztben mindig a Turbo Pascal 5.0-val fordítjuk le ugyanazt a viszonylag nagy, több file-ból álló programot (75 Kbyte-os .EXE-vé). a dBase tesztben tipikus adatbázis-mûveleteket futtatunk. A DOS teszt tipikus file-mûveletekbôl áll, ám hiányzik belôle a nagyobb adatmennyiségek írása-olvasása. Ezek azok a tesztek, amelyek a szabványos Eurotesztbôl leginkább jelzik a lemezmûveletek sebességét. (Lásd még októberi cikkünket, ott teljes adatsort mértünk.) Ezt kiegészítettük az MS DOS 5.0 összes file-jának ARJ-vel való betömörítésével és a tömörített file ellenôrzésével (@KARJ a /jt1@N), valamint 30 Mbyte-nyi, tömöríthetetlen adat lemezreírásával és visszaolvasásával (64 Kbyte-os pufferen át). Ez utóbbi mérés az adatátviteli sebességre jellemzô adatot szolgáltat, mellesleg kitûnôen jelzi, hogy mennyit foglalkozik egy-egy (röp)tömörítô a tömörítendô adatok, file-ok préselésével. A mérések során állandóan bekapcsolva hagytuk a QEMM memóriakezelôt, @KRAM@N állásban. @KDOS=HIGH@N beállítás mellett így 610 Kbyte szabad memória maradt a SuperStor 1.07, s 631 Kbyte a Stacker 3.00 használata esetén. Ahol a HyperDisk lemezgyorsító (cache) program 4.31 shareware változatát használtuk, ott ""(cache)" megjegyzéssel jeleztük ezt. A cache célú memória ekkor 1024 Kbyte volt. Az Euroteszten kívüli méréseket a memórialemezen (RAMDRIVE) csak több részre bontva tudtuk elvégezni, de ez nem befolyásolja az eredmények jelentését. A dBase teszt most sem futott le a Stacker alatt -- sajnos a 3.00 verzió sem javították ki. A QEMM az ismételt próbálkozások egyike alkalmával ki is írta a lefagyás okát: érvénytelen utasításkód. Mivel ez már a harmadik gép, ahol ezt tapasztaltuk, egyértelmûen a Stacker a hibás, és egy korábbi cikkünk Stackertôl átvett megjegyzése is megkérdôjelezhetô, miszerint egy korai ALR BusinessVEISA alaplap lenne a vétkes abban, hogy nem fut rajta a Stacker... A mérések kiértékelése minket is meghökkentett. A DOS alatti dBase mérést ismételten elvégeztük, hibára gyanakodva. A merevlemez LED-jét figyelve látszott, hogy a dBase minden mûveletet a HyperDisk által kezelt cache-ben végez, ennek tudható be a hihetetlen sebesség. Hogy a DOS RAMDRIVE programjával létrehozott memórialemez miért volt lassabb a cache-elt DOS-nál? Talán a HyperDisk okosabb a RAMDRIVE.SYS-nél... Nem tudjuk. Feltûnô még a nyers adatátviteli mérések eredménye. DOS alatt a cache ilyenkor csak lassít, mert többször kell átrakosgatni a memóriában az adatokat. A FAT-kezelés viszont ilyenkor is gyorsul, ez is látszik a kissé ellentmondó adatok részletes elemzésekor. Ennek a mérésnek a kivételével mindenütt jótékony hatású a cache. Látszik, hogy a Stacker új verziója nem lett gyorsabb, s nagyon feltûnô, hogy nagy adatmennyiségek átvitelénél mennyire lassú minden röptömörítô, még a SuperStor is. Ezért a Windows cserefile-jaihoz, kép- és hangfile-ok (multimédia) kezelésére, adatbázisokhoz röptömörített (virtuális) lemezeket ugyan lehet használni (még Stackert is), de többnyire nem érdemes. Ha van elég memória, akkor azt ilyenkor használjuk memórialemezként, illetve a Windows esetén hagyjuk meg azt memóriának. Az eredmények további, részletekbe menô elemzését az Olvasókra hagyjuk. @VSuperStor -- hogyan használjuk?@N Néhány megjegyzéssel segítenénk azokat, akik a Stacker riválisát, a SuperStort is ki szeretnék próbálni. A DR DOS-beli SuperStorok eredeti környezetükben, a DR DOS alatt kifogástalanul mûködnek. Azokon a gépeken, ahol van felsô (upper) memóriaterület, a HIDEVICE paranccsal elérhetjük, hogy csak mintegy 20 Kbyte-ot foglaljon le az alsó 640 Kbyte-ból. A SuperStor DR DOS 6.0-ból kibányászható verziója csak DR 6.0 alatt használható -- MS DOS 5.0 alatt tapasztalható hibájáról már írtunk, életveszélyes! A DR DOS 6.01 mellé adott verzió korrektül mûködik MS DOS 5.0 alatt is, még a Windows 3.1-gyel sincs problémája (naná, hiszen ezért jelentette meg a Novell a DR 6.01 verzióját ""6.0 update" elnevezéssel). Viszont MS DOS 5.0 alatt nem lehet visszahozni a SuperStor által kezelt virtuális meghajtókon a törölt file-okat a szokásos módon, például a Norton Unerase-zel, Quick Unerase-zel. Aki MS DOS 5.0-t és SuperStort akar használni egyszerre, annak számolnia kell ezzel a bakival. És azzal is, hogy MS DOS 5.0 alatt a DR 6.01-beli SuperStor meghajtóprogramja nem tölthetô fel a felsô memóriaterületre, csak ha a QEMM 386 memóriakezelôt használatuk. (Más memóriakezelôkkel nem próbálkoztunk -- a QEMM alatt viszont automatikusan felrakja a felsô memóriába önmagának mintegy a felét, s csak 23|696 byte marad az alsó 640 K-ban, miként DR DOS alatt.) Hosszas használata alatt nem tapasztaltunk más problémát. Az, hogy a SuperStor virtuális meghajtóin csak legfeljebb 256 file lehet egy-egy könyvtárban, rémhír. Nekünk voltak s vannak olyan könyvtáraink, amikben több mint 1000 file van (ráadásul MS DOS 5.0 alatti SuperStor meghajtókon), s -- lekopogjuk -- gond egy szál se. A fentiekhez kapcsolódik egy általános jótanács. Az operációs rendszerekhez adott meghajtóprogramokat mindig kockázatos más környezetben használni. Ha valaki mégis próbálkozik ilyesmivel, elôször próbálja ki ""határhelyzetekben" az átoperált részt. A röptömörítôknél (ilyen a SuperStor, s ilyen lesz az MS DOS 5.0 alatti DoubleDisk is), lemezgyorsító (cache) programoknál ez intenzív lemezhasználatot, a lemez csordultig írását, a gép lemezmûveletek közbeni kikapcsolását, ""kényes" programok (Windows 3.1 stb.) futtatását és hasonló helyzetek kipróbálását jelenti. Ha minden rendben, akkor is érdemes óvatosnak lenni az elsô napokban. Legfrissebb hírünk: megjelent a SuperStor 2.0 továbbfejlesztett változata, SuperStor Pro néven. Nekünk a SuperStornak eddig csak a DR DOS 6.0, 6.01 mellé adott (licencelt), régi változatai voltak meg (v1.03, v1.07), s nagyon jó tapasztalatokat szereztünk velük (a Stackernek csak a reklámja és ismertsége jobb, teljesítménye gyengébb nála). Kíváncsian várjuk, mit hoz a két vezetô röptömörítô legújabb verzióinak összecsapása. Stacker for Windows and DOS SETUP ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░╔═══════════════════════════ Tune Stacker ════════════════════════════╗░░░░ ░░░░║ ║░░░░ ░░░░║ Stacker can maximize either the speed or the amount of ║░░░░ ░░░░║ compression. ║░░░░ ░░░░║ ║░░░░ ░░░░║ You can change this setting after Setup by using Stacker ║░░░░ ░░░░║ Tuner from Stacker Toolbox. ║░░░░ ░░░░║ ║░░░░ ░░░░║ Speed/Space Balance:──────────────────────────────────────┐ ║░░░░ ░░░░║ │ (») More Speed │ Fastest speed and standard compression │ ║░░░░ ░░░░║ │ ( ) Balanced │ More compression and a bit less speed │ ║░░░░ ░░░░║ │ ( ) More Space │ Best compression │ ║░░░░ ░░░░║ └─────────────────────────────────────────────────────────┘ ║░░░░ ░░░░║ ║░░░░ ░░░░║ Continue ▄ Help ▄ Exit ▄ ║░░░░ ░░░░║ ▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀▀ ║░░░░ ░░░░╚═════════════════════════════════════════════════════════════════════╝░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ Press F1 for Help Bár viszonylag szûk határok közt, de bármikor módosítható a sebesség/tömörség arány Stacker for Windows and DOS Stacker Toolbox ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░╔══════════════════════════ Stacker Toolbox ═══════════════════════════╗░░ ░░░║ ║░░ ░░░║ ══════ Stack ══════════ ┌──────── Configure...Passwords ─────────┐ ║░░ ░░░║ Hard Disk │Stacker lets you use passwords with │ ║░░ ░░░║ Floppy (removable) │stacked disks. With this tool, you can │ ║░░ ░░░║ Unstack │assign a password to: │ ║░░ ░░░║ │ │ ║░░ ░░░║ ══════ Check ══════════ │ - Allow read/write access │ ║░░ ░░░║ Drive Integrity │ │ ║░░ ░░░║ Compression Report │ - Allow read-only access │ ║░░ ░░░║ │ │ ║░░ ░░░║ ══════ Optimize ═══════ │You can also: │ ║░░ ░░░║ Stacker Optimizer │ │ ║░░ ░░░║ Stacker Tuner │ - Change an existing password │ ║░░ ░░░║ │ │ ║░░ ░░░║ ══════ Configure ══════ │ - Remove a Stacker password │ ║░░ ░░░║ Stacker Drive Size │ │ ║░░ ░░░║ Expected Compression │After you press Enter, choose the │ ║░░ ░░░║ » Passwords │Stacker drive. │ ║░░ ░░░║ └────────────────────────────────────────┘ ║░░ ░░░╚════════════════════════════════════════════════════════════════════════╝░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ F1 for help. Arrows () to select. F10 to exit. A két fokozatú jelszavas védelem nagyon hasznos újdonság Stacker for Windows and DOS Report ░░┌──────────────────────────────── Actions ─────────────────────────────────┐░ ░░│ Show Files Show Summary Change Drive │░ ░░└──────────────────────────────────────────────────────────────────────────┘░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ┌─ Sort By ──┐░╔═══════════════ File Information for Drive C: ═══════════════╗░ │ │░║ File File D:\STACVOL.DSK % of Compression ║░ │»Extension │░║ Extension Count Disk Usage Total Ratio ║░ │ │░║ ─────────────────────────────────────────────────────────── ║░ │ File Count │░║ EXE 198 8,517,120 8.37% 1.6:1 ║░ │ │░║ COM 57 632,320 0.62% 1.9:1 ║░ │ Disk Usage │░║ HLP 53 2,082,816 2.05% 1.8:1 ║░ │ │░║ CFG 39 26,112 0.03% 13.5:1 ║░ │ Comp Ratio │░║ TXT 33 82,944 0.08% 4.3:1 ║░ │ │░║ PCX 32 238,592 0.23% 4.5:1 ║░ └────────────┘░║ SYS 27 259,072 0.25% 2.2:1 ║░ ░░░░░░░░░░░░░░░║ DLL 26 695,296 0.68% 2.3:1 ║░ ┌─Sort Order─┐░║ GX2 19 146,432 0.14% 2.0:1 ║░ │ │░║ BMP 19 55,808 0.05% 5.0:1 ║░ │+ Ascending │░║ FON 16 143,360 0.14% 2.8:1 ║░ │ │░║ INI 15 18,944 0.02% 8.2:1 ║░ │- Descending│░║ FOT 14 7,168 0.01% 16.0:1 PgDn ║░ │ │░║ SU 14 28,672 0.03% 4.0:1 ║░ └────────────┘░╚═════════════════════════════════════════════════════════════╝░ F1 for Help. PgUp, PgDn, Home, and End to examine statistics. F10 to Exit. Részletes beszámolót kérhetünk a file-ok tömörítési arányáról -- itt éppen a kiterjesztés szerinti áttekintést böngésztünk